第四個原則

前面介紹策略模式時，就提到過設計的程式希望是有彈性的，而 鬆耦合(lossely coupled) 就可以提升程式的彈性。所謂的鬆耦合，就是降低物件間的依賴關係；當物件彼此關係密切，例如A物件的某資料成員改變，會導致B物件的成員跟著改變，這個影響越劇烈代表越耦合，而要讓程式可以輕易的改動，這耦合關係自然就是越低越好。白話一點，我們希望降低牽A "一髮" ，動B "全身" 的耦合狀態，理想是動A "全身" ，只會影響到B "一髮" 的鬆耦合。

因此，第四個設計原則如下：

努力為彼此互動的物件做出鬆耦合的設計。

而觀察者模式便具有良好的鬆耦合特性。

觀察者模式與鬆耦合

我們可以來檢視觀察者模式中的鬆耦合特性。

• 當我們改動observer的介面...：
  • As-is? :依據前天未優化前的寫法，subject必須相應的改變measurementsChanged()裡面的實作
  • With observer pattern ?: subject根本不在乎！
• 當我們移除/ 新增observer的介面...：
  • As-is? : 寫死在weatherData()裡面，執行期無法更動！
  • With observer pattern ?: 完全不需要修改subject!!
• 當我們修改subject...：
  • With observer pattern ?: 只要interface未做更動，完全不需要修改observer!

修改後的架構

現在，我們依照前一天的觀察者模式類別圖，將氣象應用程式仿作一遍：

而程式碼實作，大致如下：

• 首先是兩個介面:

class Observer
{
    public:
        void update();
};

class Subject
{
    public:
        void registerObserver(Observer o);
        void removeObserver(Observer o);
        void notifyObservers();
};

• 接下來則是subject- WeatherData()的實作:

class WeatherData: public Subject
{
    public:
        void registerObserver(Observer *o) override
        {
            observers.push_back(o);
        }

        void removeObserver(Observer *o) override
        {
            auto it = std::find(observers.begin(), observers.end(), o);
            if (it != observers.end())
            {
                observers.erase(it);
            }
        }

        void notifyObservers() override
        {
            for(auto observer: observers)
            {
                observer->update();
            }
        }
    private:
        std::vector<Observer *> observers;
        float temperature = 0;
        float humidity = 0;
        float pressure = 0;
};

• 最後則是observer- 各種display的實作:

/*程式碼待補*/

• 實際測試看看！

/*程式碼待補*/

結語

結束了觀察者模式，接下來就是第三章 裝飾器模式 了。
現在已經累積了好幾條原則與模式定義了：OO基本4概念、4道原則、2個設計模式定義；不妨複習一下，並觀察接觸到的程式中是否有可以應用這些模式的地方。